[Previous] [Next] [Index]
[Thread]
Re: GSS API (as a DLL)...
At 03:27 PM 8/17/94 TZ, John Ludeman wrote:
>
>----------
>| From: "Alec H. Peterson" <chuckie@panix.com>
>| Date: Wednesday, August 17, 1994 4:46PM
>|
>| Ramin Firoozye writes:
>| [...]
>| >
>| >The BIG problem specific to security DLL's is that someone bent on breaking
>| >security can write a "wrapper" DLL around a security DLL, store all the
>| >[...]
>|
>| This is one of the reasons why most (if not all) applications that deal with
>| secure data (like /bin/login and /bin/su) should be statically linked.
>
>No, this is not a valid reason. The above argument implies there is no
>security. If a sysadmin doesn't want this to happen, they must take the
>appropriate security percautions. If they do not, then *nothing* in
>the system is secure and any program the system might run can do bad
>things. This again gets into site security issues which is beyond the
>topic of this alias.
I'm inclined to agree. If you can compromise the users loader library
search path, then you're probably in a position to compromise the path used
to load
applications as well, and anything you could do by wrapping the security
services you could just do by replacing the client application. Similarly, if
the server is run by a user (and many must be, if all the servers on port
8001 are any indicator) then the same argument applies.
Making user=sysadmin (as in the case of a unix daemon server started at boot)
just means that you have to compromise the system rather than a user, but the
argument is really identical: if you can wrap a library, you can probably
substitute an application binary too.
There are certainly times when dynamic libraries are inappropriate, but this
doesn't seem to me to be one of them.
Ken
-----
Ken Shores, Sr. Network Analyst The Charles Stark Draper Laboratory, Inc.
kss1376@pop.draper.com 555 Technology Square, Cambridge, MA 02139-3563
(617) 258-2529 Mail Stop 33
Follow-Ups: